In hospitals, clinics or other medical facilities, it is standard for the doctor to use a wealth of medical appliances to treat patients or to perform other tasks. The medical appliances themselves are usually controlled using computer systems. The computer systems e.g. PCs, provide a series of in some cases highly specialized tools, also called medical applications.
DE 695 24 434 and EP 1 769 771 each show an example of a graphical user interface in a respective single medical application. The medical application in DE 695 24 434 shows a control application for an apparatus for neurosurgical interventions. EP 1 769 771 shows an application for computer-aided display of a workflow for orthopedic surgical interventions.
These tools are controlled using control elements, to be more precise activation elements, which are displayed on the computer system's user interface. On account of the large number of tools available, it is not possible to present all the activation elements on the user interface. This lack of space on the user interface is also aggravated by the fact that generally not only activation elements are displayed but also the medical data to be edited.
To date, the space problem on the user interface has been solved by displaying only those activation elements which are used frequently. Activation elements which are used less often are frequently not displayed directly. In this case, the doctor needs to use a menu, for example, for selection and to operate a button or to use further options (e.g. a mouse click). By contrast, some systems are adaptive and place frequently used tools onto the directly accessible user interface after some time, while other systems provide use configuration, for example, so that each user, that is to say the doctor, for example, can himself decide which tools he wishes to access directly.
However, the previous methods for providing activation elements on the user interface have a series of drawbacks. Thus, the search for activation elements which are not displayed is highly time consuming, in particular. In addition, the current context which prompts the doctor to use a particular tool is not utilized or taken into account. The current context is generally provided through clinical questioning or a medical indication.
By way of example, one could imagine a doctor who, upon taking on a patient in casualty, needs to make a quick diagnosis and uses a medical appliance (e.g. a tomograph), to quickly obtain information about the indication. In this case, it is crucially important to find tools used for the diagnosis quickly. There is thus the problem that the wealth of tools available means that quick and efficient editing of medical data is made difficult. Since the medical context, that is to say the clinical questioning or the medical indication, is not taken into account for providing the tool, inefficiency arises in the use of the medical appliances—the information provided by the medical context lies idle and is not used for providing the tools in anticipatory fashion on the basis of this medical context.
Another problem is to present the medical data, e.g. the images, together with the activation elements such that the activation elements do not conceal or cover the images.
Another problem can also be seen as being that the aforementioned problems need to be solved using the capabilities of the existing IT infrastructure. The resultant cost saving is desirable directly in view of the strained budget of medical facilities (health insurance funds, hospitals, doctors' practices).